Dr. Jingwei Yang
Dialog Semiconductor has produced an edge device server called the SmartServerIoT. This device is designed to be used in environments consisting of hundreds to thousands of IoT devices. This hardware must be tested to verify performance and stability while maximizing the number of devices supported at a time.
The project proposed will interact with the SmartServerIoT by simulating devices and communicating over twisted pair using the LonTalk protocol. The simulator produced will assist in testing the stability of the SmartServerIoT while under high-load. The ultimate goal of this project is to be able to simulate 2,000 devices with a single simulator running on one machine.
A software simulator that creates and manages thousands of IzoTDevices. This simulator will run on a Linux machine. These simulated devices will directly interact with the SmartServerIoT over LonTalk.
In this project, we will be producing a piece of software that interacts with real world hardware. While Dialog Semiconductor already has a simulator capable of performing this task, their existing solution is lacking several key features. Our proposed solution will be capable of simulating a large pool of devices on a Linux machine.
We initially set out using C++ to build the project, as we wanted to be able to have enough performance to ensure that we could simulate as many devices as possible. However, midway through the project, we learned that our original design did not work with the client-provided C-based LonTalk framework, which only supports a single device per framework stack and only one stack per process. We carefully planned a re-architecture of our project, settling on a C++ device to interface with the LonTalk framework and a Python runner to orchestrate all the device processes.
We provided a REPL interface to give the user control over the C++ devices which are managed by the Python simulator. The REPL handles creating new devices by starting new processes, as well as any user-requested actions, ranging from temporarily shutting down devices to asking the device process to modify device datapoints or perform network actions. The C++ device handles network communication by delegating the bulk of the work to the LonTalk framework, instead focusing on responding to requests from the Python runner to perform actions and display information.
Special thanks to the team at Dialog Semiconductor that worked with us throughout development. Without their
assistance and constant oversight on our progress, development on Mockingbird would have never reached
Special thanks to our professor Dr. Jingwei Yang for his guidance throughout these two semesters and our lab adviser Dr. Ying Jin who provided much needed advice throughout Mockingbird's development, enabling us to keep our end goal constantly in sight.
Team NULL was formed and begin finalizing plans with Dialog Semiconductor to produce the Mockingbird simulator.
August 31, 2020
The project charter was drafted by team NULL following the guidelines of our adviser. Once completed this was presented to the client for review. Later, with a few changes made, the client accepted our charter and signed it. In addition to the product charter our team produced a context diagram to demonstrate our current understanding of our products "work."
September 28, 2020
Several low-fidelity prototypes were produced. These took the form of system/activity diagrams. Initially each team member (or small group) produced an individual prototype (prototype A). These were then merged into two prototypes labelled prototype B, by combining the best elements of each. Later, with feedback from the client these were adapted to become prototype C.
October 12, 2020
During this Sprint our team focused on developing the inner workings of the high-fidelity prototype. Team NULL decided that the high-fidelity prototype would be produced in code (C++) and show off the user-feedback elements of the software without implementing any actual functionality with the SmartServerIoT.
October 26, 2020
Team NULL finalized the high-fidelity prototype and began work on producing the product backlog and product website.
November 9, 2020
Work on the product website/backlog was concluded during this sprint and submitted for review. In addition, a project prototype document was produced.
November 23, 2020
In this sprint team NULL performed extensive research on the client's framework. This involved reading documentation provided to us involving LonTalk devices. In addition, research was performed on how to simulate IoT devices in C++. Lastly, effort was put into setting up an automated testing environment.
February 3, 2021
Development environments were setup for each team member. This involved installing the IzoT framework on the machines the team planned to use for development. In order to accomplish this, team NULL participated in several meetings with the client to work out difficulties. This eventually led to a virtual machine running Ubuntu 15 being setup so that our client could perform the necessary installation steps and work through the many issues that were encountered.
February 20, 2021
Due to time restrictions, team NULL began fleshing out the features of Mockingbird by modifying the existing High-Fidelity prototype. The intention behind this effort was to implement all of the simulators features without implementing the LonTalk code. Alongside these efforts, certain team members continued working on the IzoT framework, compiling the C libraries from source. This included an example IzoTDevice that we could use to verify system functionality.
March 6, 2021
After many discussions with the client on our existing work, Mockingbird undertook an extensive framework change. Due to the success of our team last sprint we were able to compile and run the simple IzoTDevice provided by the client. In light of our newfound knowledge we decided to use this device (with extensive modification) to perform all the LonTalk communication between are client's hardware and our simulator. To accomplish this goal we scrapped the previous version of Mockingbird. This was replaced by a Python script that was capable of creating, managing, and communicating with these devices. In this sprint we managed to implement all previous features alongside a few additional ones getting Mockingbird to 100% base functionality.
March 20, 2021
During this sprint team NULL showed off the new Mockingbird to the client. They were pleased to see the results of our efforts and highlighted a few features that were missing. In response to this, certain team members were assigned to implement these missing features. In addition, several known bugs were tackled. This included a library swap in Mockingbird. Previously the Subprocess library was used to manage the devices. However, after testing we found that the Pexpect library proved more reliable.
April 3, 2021
The end goal of this sprint was to create the first stable version of Mockingbird that would be ready-for-release. This involved created extensive documentation on how to use and modify Mockingbird. Alongside this, team NULL began working on quality assurance. Testing Mockingbird and fixing bugs as they were found. Lastly, enhancements to existing features were developed in order to provide a consistent interface to the user.
April 17, 2021
At the beginning of this sprint team NULL informed the client that the product was ready to deliver. Existing documentation was modified as per the clients request with any small changes to Mockingbird implemented. In addition, deliverables were finalized and submitted to our adviser for review.
May 1, 2021
Mockingbird delivery deadline. On this date team NULL delivered the product (as is) to Dialog Semiconductor.
May 14, 2021